WebGL Transform Feedback ietekme uz veiktspēju: Virsotņu uztveršanas apstrādes pieskaitāmās izmaksas

WebGL Transform Feedback (TF) ir jaudīga funkcija, kas ļauj izstrādātājiem uztvert virsotņu vai ģeometrijas ēnotāju izvadi un padot to atpakaļ grafikas konveijeram vai nolasīt to tieši CPU. Šī iespēja paver plašas iespējas sarežģītām simulācijām, uz datiem balstītai grafikai un GPGPU stila aprēķiniem pārlūkprogrammā. Tomēr, kā jebkurai progresīvai funkcijai, tai ir savi veiktspējas apsvērumi, īpaši attiecībā uz virsotņu uztveršanas apstrādes pieskaitāmajām izmaksām. Šis bloga ieraksts iedziļināsies šo pieskaitāmo izmaksu sarežģītībā, to ietekmē uz renderēšanas veiktspēju un stratēģijās, kā mazināt to negatīvo ietekmi globālai tīmekļa izstrādātāju auditorijai.

Izpratne par WebGL Transform Feedback

Pirms mēs iedziļināmies veiktspējas aspektos, īsi atkārtosim, kas ir Transform Feedback un kā tas darbojas WebGL.

Pamatjēdzieni

• Virsotņu uztveršana: Transform Feedback galvenā funkcija ir uztvert virsotnes, ko ģenerējis virsotņu vai ģeometrijas ēnotājs. Tā vietā, lai šīs virsotnes tiktu rasterizētas un nosūtītas uz fragmentu ēnotāju, tās tiek ierakstītas vienā vai vairākos bufera objektos.
• Bufera objekti: Tie ir uztverto virsotņu datu galamērķi. Jūs piesaistāt vienu vai vairākus ARRAY_BUFFER transformācijas atgriezeniskās saites objektam, norādot, kuri atribūti jāieraksta kurā buferī.
• Varying mainīgie: Atribūti, kurus var uztvert, tiek deklarēti kā 'varying' ēnotāja programmā. Var uztvert tikai varying izvades no virsotņu vai ģeometrijas ēnotāja.
• Renderēšanas režīmi: Transform Feedback var izmantot dažādos renderēšanas režīmos, piemēram, uztverot atsevišķus punktus, līnijas vai trīsstūrus.
• Primitīvu restartēšana (Primitive Restart): Šī ir būtiska funkcija, kas ļauj veidot nesavienotus primitīvus vienā zīmēšanas izsaukumā, izmantojot Transform Feedback.

Transform Feedback pielietojuma gadījumi

Transform Feedback nav tikai tehnisks kuriozs; tas nodrošina nozīmīgus panākumus tajā, kas ir iespējams ar WebGL:

• Daļiņu sistēmas: Miljoniem daļiņu simulācija, to pozīciju un ātrumu atjaunināšana uz GPU un pēc tam to efektīva renderēšana.
• Fizikas simulācijas: Sarežģītu fizikas aprēķinu veikšana uz GPU, piemēram, šķidruma dinamikas vai auduma simulācijas.
• Instancēšana ar dinamiskiem datiem: Dinamiska instances datu atjaunināšana uz GPU progresīvām renderēšanas tehnikām.
• Datu apstrāde (GPGPU): GPU izmantošana vispārējiem aprēķiniem, piemēram, attēlu apstrādes filtriem vai sarežģītai datu analīzei.
• Ģeometrijas manipulācija: Ģeometrijas modificēšana un ģenerēšana reāllaikā, kas ir īpaši noderīgi procedurāla satura ģenerēšanai.

Veiktspējas vājā vieta: Virsotņu uztveršanas apstrādes pieskaitāmās izmaksas

Lai gan Transform Feedback piedāvā milzīgu jaudu, virsotņu datu uztveršanas un rakstīšanas process nav bez maksas. Tieši šeit parādās virsotņu uztveršanas apstrādes pieskaitāmās izmaksas. Šīs pieskaitāmās izmaksas attiecas uz skaitļošanas izmaksām un resursiem, ko patērē GPU un WebGL API, lai veiktu virsotņu uztveršanas operāciju.

Faktori, kas veicina pieskaitāmās izmaksas

1. Datu serializācija un rakstīšana: GPU ir jāņem apstrādātie virsotņu dati (atribūti, piemēram, pozīcija, krāsa, normāles, UV koordinātes utt.) no saviem iekšējiem reģistriem, jāserializē tos atbilstoši norādītajam formātam un jāieraksta piesaistītajos bufera objektos. Tas ietver atmiņas joslas platumu un apstrādes laiku.
2. Atribūtu kartēšana: WebGL API ir pareizi jākartē ēnotāja 'varying' izvades uz norādītajiem atribūtiem transformācijas atgriezeniskās saites buferī. Šī kartēšana ir jāpārvalda efektīvi.
3. Bufera pārvaldība: Sistēmai ir jāpārvalda rakstīšanas process uz potenciāli vairākiem izvades buferiem. Tas ietver bufera pārpildes, apgrozījuma apstrādi un datu integritātes nodrošināšanu.
4. Primitīvu salikšana/izjaukšana: Strādājot ar sarežģītiem primitīviem vai izmantojot primitīvu restartēšanu, GPU var būt nepieciešams veikt papildu darbu, lai pareizi sadalītu vai saliktu primitīvus uztveršanai.
5. Konteksta pārslēgšana un stāvokļa pārvaldība: Transformācijas atgriezeniskās saites objektu piesaistīšana un atsaistīšana, kā arī saistīto bufera objektu un varying mainīgo konfigurāciju pārvaldība var radīt stāvokļa pārvaldības pieskaitāmās izmaksas.
6. CPU-GPU sinhronizācija: Ja uztvertie dati tiek nolasīti atpakaļ uz CPU (piemēram, tālākai apstrādei vai analīzei no CPU puses), ir iesaistītas ievērojamas sinhronizācijas izmaksas. Tas bieži vien ir viens no lielākajiem veiktspējas kavētājiem.

Kad pieskaitāmās izmaksas kļūst nozīmīgas?

Virsotņu uztveršanas apstrādes pieskaitāmo izmaksu ietekme ir visizteiktākā scenārijos, kas ietver:

• Liels virsotņu skaits: Datu apstrāde un rakstīšana ļoti lielam virsotņu skaitam katrā kadrā.
• Daudzi atribūti: Daudzu dažādu virsotņu atribūtu uztveršana katrai virsotnei palielina kopējo rakstāmo datu apjomu.
• Bieža Transform Feedback izmantošana: Nepārtraukta Transform Feedback ieslēgšana un izslēgšana vai pārslēgšanās starp dažādām TF konfigurācijām.
• Datu nolasīšana atpakaļ uz CPU: Šis ir kritisks vājais posms. Lielu datu apjomu nolasīšana no GPU atpakaļ uz CPU ir pēc būtības lēna, jo atmiņas telpas ir atdalītas un ir nepieciešama sinhronizācija.
• Neefektīva bufera pārvaldība: Nepareiza buferu izmēru pārvaldība vai dinamisku buferu izmantošana bez rūpīgas apsvēršanas var radīt veiktspējas sodus.

Veiktspējas ietekme uz renderēšanu un aprēķiniem

Virsotņu uztveršanas apstrādes pieskaitāmās izmaksas tieši ietekmē jūsu WebGL lietojumprogrammas kopējo veiktspēju vairākos veidos:

1. Samazināti kadru nomaiņas ātrumi

Laiks, ko GPU pavada virsotņu uztveršanai un buferu rakstīšanai, ir laiks, ko nevar veltīt citiem renderēšanas uzdevumiem (piemēram, fragmentu ēnošanai) vai skaitļošanas uzdevumiem. Ja šīs pieskaitāmās izmaksas kļūst pārāk lielas, tas tieši pārvērtīsies zemākos kadru nomaiņas ātrumos, radot mazāk plūstošu un atsaucīgu lietotāja pieredzi. Tas ir īpaši svarīgi reāllaika lietojumprogrammām, piemēram, spēlēm un interaktīvām vizualizācijām.

2. Palielināta GPU slodze

Transform Feedback rada papildu slogu GPU virsotņu apstrādes vienībām un atmiņas apakšsistēmai. Tas var novest pie augstākas GPU izmantošanas, potenciāli ietekmējot citu GPU saistītu operāciju veiktspēju, kas darbojas vienlaicīgi. Ierīcēs ar ierobežotiem GPU resursiem tas ātri var kļūt par ierobežojošu faktoru.

3. CPU vājie posmi (īpaši ar datu nolasīšanu atpakaļ)

Kā minēts, ja uztvertie virsotņu dati bieži tiek nolasīti atpakaļ uz CPU, tas var radīt ievērojamu CPU vājo posmu. CPU ir jāgaida, kamēr GPU pabeidz rakstīšanu, un pēc tam, kamēr pabeigta datu pārsūtīšana. Šis sinhronizācijas solis var būt ļoti laikietilpīgs, īpaši lieliem datu apjomiem. Daudzi izstrādātāji, kas ir jauni Transform Feedback lietotāji, nenovērtē GPU-uz-CPU datu pārsūtīšanas izmaksas.

4. Atmiņas joslas platuma patēriņš

Lielu virsotņu datu apjomu rakstīšana bufera objektos patērē ievērojamu atmiņas joslas platumu uz GPU. Ja jūsu lietojumprogramma jau ir intensīvi izmanto atmiņas joslas platumu, Transform Feedback pievienošana var saasināt šo problēmu, izraisot citu atmiņas operāciju ierobežošanu.

Stratēģijas virsotņu uztveršanas apstrādes pieskaitāmo izmaksu mazināšanai

Pieskaitāmo izmaksu avotu izpratne ir pirmais solis. Nākamais ir stratēģiju ieviešana to ietekmes mazināšanai. Šeit ir vairākas galvenās tehnikas:

1. Optimizējiet virsotņu datus un atribūtus

• Uztveriet tikai nepieciešamos atribūtus: Neuztveriet atribūtus, kas jums nav nepieciešami. Katrs atribūts palielina datu apjomu un rakstīšanas procesa sarežģītību. Pārskatiet savas ēnotāja izvades un pārliecinieties, ka tiek uztverti tikai būtiski varying mainīgie.
• Izmantojiet kompaktus datu formātus: Kad vien iespējams, izmantojiet viskompaktākos datu tipus saviem atribūtiem (piemēram, FLOAT_HALF_BINARY16, ja precizitāte to atļauj, vai izmantojiet mazākos veselo skaitļu tipus). Tas samazina kopējo rakstāmo datu apjomu.
• Kvantizācija: Noteiktiem atribūtiem, piemēram, krāsai vai normālēm, apsveriet to kvantizāciju uz mazāku bitu skaitu, ja vizuālā vai funkcionālā ietekme ir nenozīmīga.

2. Efektīva bufera pārvaldība

• Gudri izmantojiet Transform Feedback buferus: Izlemiet, vai jums ir nepieciešams viens vai vairāki izvades buferi. Vairumam daļiņu sistēmu efektīvs var būt viens buferis, kas tiek mainīts starp lasīšanu un rakstīšanu.
• Dubultā vai trīskāršā buferizācija: Lai izvairītos no dīkstāvēm, nolasot datus atpakaļ uz CPU, ieviesiet dubulto vai trīskāršo buferizāciju. Kamēr viens buferis tiek apstrādāts uz GPU, citu var nolasīt CPU, un trešo var atjaunināt. Tas ir būtiski GPGPU uzdevumiem.
• Bufera izmērs: Iepriekš iedaliet buferus ar pietiekamu izmēru, lai izvairītos no biežas atkārtotas iedalīšanas vai pārpildes. Tomēr izvairieties no pārmērīgas pār-iedalīšanas, kas tērē atmiņu.
• Bufera atjauninājumi: Ja jums ir jāatjaunina tikai daļa no bufera, izmantojiet metodes, piemēram, glBufferSubData, lai atjauninātu tikai mainītās daļas, nevis augšupielādētu visu buferi no jauna.

3. Minimizējiet GPU-uz-CPU datu nolasīšanu

Šī, iespējams, ir vissvarīgākā optimizācija. Ja jūsu lietojumprogrammai patiešām ir nepieciešami dati uz CPU, apsveriet, vai ir veidi, kā samazināt nolasīšanas biežumu vai apjomu:

• Apstrādājiet datus uz GPU: Vai nākamie apstrādes soļi var tikt veikti arī uz GPU? Sasaistiet vairākas Transform Feedback pārejas.
• Nolasiet atpakaļ tikai absolūti nepieciešamo: Ja jums ir jānolasa atpakaļ, iegūstiet tikai konkrētus datu punktus vai kopsavilkumus, nevis visu buferi.
• Asinhrona nolasīšana (ierobežots atbalsts): Lai gan īsta asinhrona nolasīšana nav standarts WebGL, dažas pārlūkprogrammas var piedāvāt optimizācijas. Tomēr paļauties uz tām parasti nav ieteicams starppārlūku saderības dēļ. Lai veiktu progresīvākas asinhronas operācijas, apsveriet WebGPU.
• Taupīgi izmantojiet glReadPixels: glReadPixels ir paredzēts nolasīšanai no tekstūrām, bet, ja jums ir nepieciešams iegūt bufera datus uz CPU, jums bieži vien vispirms būs jārenderē bufera saturs tekstūrā vai jāizmanto gl.getBufferSubData. Pēdējais parasti ir ieteicamāks neapstrādātiem bufera datiem.

4. Optimizējiet ēnotāja kodu

Lai gan mēs koncentrējamies uz pašu uztveršanas procesu, neefektīvi ēnotāji, kas padod datus Transform Feedback, var netieši pasliktināt veiktspēju:

• Minimizējiet starpposma aprēķinus: Pārliecinieties, ka jūsu ēnotāji ir pēc iespējas efektīvāki, samazinot aprēķinus katrai virsotnei pirms tās izvades.
• Izvairieties no nevajadzīgām varying izvadēm: Deklarējiet un izvadīt tikai tos varying mainīgos, kas ir paredzēti uztveršanai.

5. Stratēģiska Transform Feedback izmantošana

• Nosacījuma atjauninājumi: Ja iespējams, ieslēdziet Transform Feedback tikai tad, kad tas patiešām ir nepieciešams. Ja noteiktiem simulācijas soļiem nav nepieciešami GPU atjauninājumi, izlaidiet TF pāreju.
• Operāciju grupēšana: Grupējiet saistītās operācijas, kurām nepieciešams Transform Feedback, lai samazinātu TF objektu piesaistīšanas un atsaistīšanas un stāvokļa maiņu pieskaitāmās izmaksas.
• Izprotiet primitīvu restartēšanu: Efektīvi izmantojiet primitīvu restartēšanu, lai zīmētu vairākus nesavienotus primitīvus vienā zīmēšanas izsaukumā, kas var būt efektīvāk nekā vairāki zīmēšanas izsaukumi.

6. Apsveriet WebGPU

Lietojumprogrammām, kas paplašina WebGL iespēju robežas, īpaši attiecībā uz paralēliem aprēķiniem un progresīvām GPU funkcijām, ir vērts apsvērt pāreju uz WebGPU. WebGPU piedāvā modernāku API ar labāku kontroli pār GPU resursiem un bieži vien var nodrošināt paredzamāku un augstāku veiktspēju GPGPU stila uzdevumiem, ieskaitot robustākus veidus, kā rīkoties ar bufera datiem un asinhronām operācijām.

Praktiski piemēri un gadījumu izpēte

Apskatīsim, kā šie principi tiek piemēroti bieži sastopamos scenārijos:

1. piemērs: Liela mēroga daļiņu sistēmas

Scenārijs: Simulē 1 000 000 daļiņu. Katrā kadrā to pozīcijas, ātrumi un krāsas tiek atjauninātas uz GPU, izmantojot Transform Feedback. Atjauninātās daļiņu pozīcijas pēc tam tiek izmantotas, lai zīmētu punktus.

Pieskaitāmo izmaksu faktori:

• Liels virsotņu skaits (1 000 000 virsotņu).
• Potenciāli vairāki atribūti (pozīcija, ātrums, krāsa, dzīves ilgums utt.).
• Nepārtraukta TF izmantošana.

Mazināšanas stratēģijas:

• Uztveriet minimālus datus: Uztveriet tikai pozīciju, ātrumu un, iespējams, unikālu ID. Krāsu var atvasināt uz CPU vai ģenerēt no jauna.
• Izmantojiet FLOAT_HALF_BINARY16 pozīcijai un ātrumam, ja precizitāte to atļauj.
• Dubultā buferizācija ātrumam, ja daļiņas ir jānolasa atpakaļ noteiktai loģikai (lai gan ideālā gadījumā visa loģika paliek uz GPU).
• Izvairieties no daļiņu datu nolasīšanas atpakaļ uz CPU katrā kadrā. Nolasiet atpakaļ tikai tad, ja tas ir absolūti nepieciešams konkrētai mijiedarbībai vai analīzei.

2. piemērs: GPU paātrināta fizikas simulācija

Scenārijs: Auduma simulācija, izmantojot Verleta integrāciju. Virsotņu pozīcijas tiek atjauninātas uz GPU, izmantojot Transform Feedback, un pēc tam šīs atjauninātās pozīcijas tiek izmantotas, lai renderētu auduma tīklu. Dažām mijiedarbībām var būt nepieciešams zināt noteiktu virsotņu pozīcijas uz CPU.

Pieskaitāmo izmaksu faktori:

• Potenciāli daudz virsotņu detalizētam audumam.
• Sarežģīti virsotņu ēnotāja aprēķini.
• Periodiska CPU nolasīšana lietotāja mijiedarbībai vai sadursmju noteikšanai.

Mazināšanas stratēģijas:

• Efektīvs ēnotājs: Optimizējiet Verleta integrācijas aprēķinus.
• Bufera pārvaldība: Izmantojiet ping-pong buferus, lai uzglabātu iepriekšējās un pašreizējās virsotņu pozīcijas.
• Stratēģiska nolasīšana: Ierobežojiet CPU nolasīšanu tikai uz būtiskiem virsotnēm vai ierobežojošo lodziņu ap lietotāja mijiedarbību. Ieviesiet lietotāja ievades debouncing, lai izvairītos no biežas nolasīšanas.
• Uz ēnotāju balstīta sadursmju noteikšana: Ja iespējams, ieviesiet sadursmju noteikšanu uz paša GPU, lai izvairītos no nolasīšanas.

3. piemērs: Dinamiska instancēšana ar GPU datiem

Scenārijs: Renderē tūkstošiem objekta instanču, kur katras instances transformācijas matricas tiek ģenerētas un atjauninātas uz GPU, izmantojot Transform Feedback no iepriekšējās aprēķinu pārejas vai simulācijas.

Pieskaitāmo izmaksu faktori:

• Liels instanču skaits nozīmē daudz transformācijas matricu uztveršanai.
• Matricu rakstīšana (bieži 4x4 pludiņpunktu skaitļi) var būt ievērojams datu apjoms.

Mazināšanas stratēģijas:

• Minimāla datu uztveršana: Uztveriet tikai nepieciešamās transformācijas matricas sastāvdaļas vai atvasinātās īpašības.
• GPU puses instancēšana: Nodrošiniet, ka uztvertie dati ir tieši izmantojami instancētai renderēšanai bez tālākas CPU manipulācijas. WebGL ANGLE_instanced_arrays paplašinājums šeit ir galvenais.
• Bufera atjauninājumi: Ja mainās tikai instanču apakškopa, apsveriet tehnikas, lai atjauninātu tikai šos konkrētos bufera reģionus.

Transform Feedback veiktspējas profilēšana un atkļūdošana

Lai identificētu un kvantificētu Transform Feedback veiktspējas ietekmi, ir nepieciešami stabili profilēšanas rīki:

• Pārlūkprogrammas izstrādātāju rīki: Vairums moderno pārlūkprogrammu (Chrome, Firefox, Edge) nodrošina veiktspējas profilēšanas rīkus, kas var parādīt GPU kadru laikus, atmiņas lietojumu un dažreiz pat ēnotāju izpildes laikus. Meklējiet straujus GPU aktivitātes vai kadru laika pieaugumus, kad Transform Feedback ir aktīvs.
• WebGL specifiski profileri: Rīki, piemēram, Frame Analyzer Chrome DevTools vai specifiski GPU ražotāju rīki, var sniegt dziļāku ieskatu zīmēšanas izsaukumos, bufera operācijās un GPU konveijera posmos.
• Pielāgota veiktspējas pārbaude: Ieviesiet savu veiktspējas pārbaudes kodu savā lietojumprogrammā. Mēriet laiku, kas nepieciešams konkrētām TF pārejām, bufera nolasīšanai un renderēšanas soļiem. Izolējiet TF operācijas, lai precīzi izmērītu to izmaksas.
• TF atspējošana: Vienkārša, bet efektīva tehnika ir nosacīti atspējot Transform Feedback un novērot veiktspējas atšķirību. Ja veiktspēja dramatiski uzlabojas, jūs zināt, ka TF ir nozīmīgs faktors.

Profilējot, pievērsiet īpašu uzmanību:

• GPU laiks: Laiks, ko GPU pavada renderēšanai un aprēķiniem.
• CPU laiks: Laiks, ko CPU pavada komandu sagatavošanai un datu apstrādei.
• Atmiņas joslas platums: Meklējiet norādes par augstu atmiņas trafiku.
• Sinhronizācijas punkti: Identificējiet, kur CPU varētu gaidīt uz GPU vai otrādi.

Globāli apsvērumi WebGL izstrādē

Izstrādājot lietojumprogrammas, kas izmanto Transform Feedback globālai auditorijai, vairāki faktori kļūst par vissvarīgākajiem:

• Aparatūras daudzveidība: Lietotāji visā pasaulē piekļūs jūsu lietojumprogrammai uz plaša ierīču klāsta, sākot no augstas klases galddatoru GPU līdz mazjaudīgām mobilajām ierīcēm un vecākām integrētām grafikām. Transform Feedback veiktspējas optimizācijas ir būtiskas, lai nodrošinātu, ka jūsu lietojumprogramma darbojas pieņemami uz plašāka aparatūras spektra. Tas, kas varētu būt nenozīmīgas pieskaitāmās izmaksas uz jaudīgas darbstacijas, varētu sagraut veiktspēju uz zemas klases planšetdatora.
• Tīkla latentums: Lai gan nav tieši saistīts ar TF apstrādes pieskaitāmajām izmaksām, ja jūsu lietojumprogramma ietver lielu datu kopu vai modeļu ielādi, kas pēc tam tiek apstrādāti ar TF, tīkla latentums var būt nozīmīgs faktors kopējā lietotāja pieredzē. Optimizējiet datu ielādi un apsveriet straumēšanas risinājumus.
• Pārlūkprogrammu implementācijas: Lai gan WebGL standarti ir labi definēti, pamatā esošās implementācijas var atšķirties starp pārlūkprogrammām un pat pārlūkprogrammu versijām. Transform Feedback veiktspējas raksturlielumi var nedaudz atšķirties. Pārbaudiet visās galvenajās pārlūkprogrammās un platformās, kas ir svarīgas jūsu mērķauditorijai.
• Lietotāju gaidas: Globālām auditorijām ir dažādas gaidas attiecībā uz veiktspēju un atsaucību. Plūstoša, interaktīva pieredze bieži ir pamatprasība, īpaši spēlēm un sarežģītām vizualizācijām. Laika investēšana TF pieskaitāmo izmaksu optimizācijā tieši veicina šo gaidu apmierināšanu.

Secinājums

WebGL Transform Feedback ir transformējoša tehnoloģija tīmekļa grafikai un aprēķiniem. Tā spēja uztvert virsotņu datus un padot tos atpakaļ konveijerā paver progresīvas renderēšanas un simulācijas tehnikas, kas iepriekš nebija pieejamas pārlūkprogrammā. Tomēr virsotņu uztveršanas apstrādes pieskaitāmās izmaksas ir kritisks veiktspējas apsvērums, kas izstrādātājiem ir jāsaprot un jāpārvalda.

Rūpīgi optimizējot datu formātus, efektīvi pārvaldot buferus, minimizējot dārgas GPU-uz-CPU nolasīšanas un stratēģiski izmantojot Transform Feedback, izstrādātāji var izmantot tā jaudu, nepakļaujoties veiktspējas vājajiem posmiem. Globālai auditorijai, kas piekļūst jūsu lietojumprogrammām uz dažādas aparatūras, rūpīga uzmanība šīm veiktspējas sekām nav tikai laba prakse — tā ir būtiska, lai nodrošinātu pārliecinošu un pieejamu lietotāja pieredzi.

Tā kā tīmeklis attīstās un WebGPU ir pie apvāršņa, šo fundamentālo GPU datu manipulācijas veiktspējas raksturlielumu izpratne joprojām ir vitāli svarīga. Apgūstiet Transform Feedback pieskaitāmās izmaksas šodien, un jūs būsiet labi sagatavoti augstas veiktspējas grafikas nākotnei tīmeklī.